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Group-Context-Aware  Mobile  Applications  1 


Context-aware  mobile  applications  are  capable  of  sensing  and 
responding  to  changes  in  their  environment  or  context 


Group-context-aware  mobile  applications  integrate  the  individual’s 
context  with  that  of  nearby  individuals  operating  as  part  of  a  group  or 
unit,  such  as  in  the  military  or  first  responder  situations 

Integrated  context  is  used  to  enhance  the 
precision  of  information  provided  to  users  as  well 
as  a  more  complete  picture  of  the  status  of  a 
mission 

•  Goal  is  to  produce  a  capability  that  can  sense 
as  much  of  the  emerging  context  as  possible 
and  apply  that  context  to  filter  data  such  that 
only  the  most  relevant  information  is  displayed 
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Group-Context-Aware  Mobile  Applications  2 


Desired  characteristics  of  the  solution 
include 


•  Capturing  context  information  on  a 
handheld  device  in  a  non-intrusive  manner 


•  Extending  the  sources  of  contextual 
information  beyond  location  and  time 

•  Storing  context  information  and 
disseminating  this  information  to  peers 

•  Capturing  and  using  context  information 
efficiently  without  imposing  an 
unreasonable  burden  on  handheld  device 
resources 


•  Integrating  local  and  group  context 
information  and  only  displaying  information 
that  is  of  relevance  to  the  individual  and 
mission  according  to  pre-defined  rules 
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Motivation 


One  of  the  more  interesting  results  of  this  work  has  been  the  ability  to 
leverage  the  architecture  to  support  collaboration 


By  identifying  extensibility  scenarios  early  on  in  the  design  process,  we 
were  able  to  construct  an  architecture  that  supports  multi-organizational 
collaboration  to  construct  and  evaluate  different  pieces  of  the 
architecture  ^ 


•  context  data  models 

•  context  data  storage 

•  context  sensors 

•  context  reasoning  engines  and  rules 

•  context  views 


This  has  allowed  us  to  reach  out  to  researchers  from  multiple 
universities  and  industry,  resulting  in  synergistic  research  and 
development,  furthering  the  goals  of  all  participants 
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Business  and  Architectural  Drivers 


Business  Drivers 

•  Opportunistic  integration  of  new  technology 

•  Ease  of  integration  with  components  produced  by  collaborators 

•  Applicability  of  architecture  to  different  edge-enabled  applications 

To  meet  business  drivers  we  defined  extensibility  as  the  main 
architectural  driver. 
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Extensibility  Scenarios 


# 

Name 

Attribute  Concern 

1 

Add  a  New  Sensor 

Separation  of  Concerns 

2 

Add  a  New  Sensor 

Modifiability 

3 

Add  a  New  Communication  Mechanism 

Separation  of  Concerns 

4 

Add  a  New  Communication  Mechanism 

Modifiability 

5 

Add  a  New  Context  Event  /  Action 

Separation  of  Concerns 

6 

Add  a  New  Context  Event  /  Action 

Modifiability 

7 

Add  a  New  Context  View 

Separation  of  Concerns 

8 

Add  a  New  Context  View 

Modifiability 
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Scenario  3:  Add  a  New  Communication  Mechanism 


Scenario 

Add  a  New  Cor 

nmunication  Mechanism 

Attribute 

Extensibility 

Attribute 

Concern 

Separation  of  C 

Concerns 

Scenario 

Stimulus 

Developer 

Refinement 

Stimulus 

Source 

Developer  identifies  a  communication  mechanism  that 
can  be  used  to  share  context  data  with  other  mobile 
devices 

Environment 

Developer  is  sufficiently  comfortable  with  application  to 
make  changes  in  a  reasonable  amount  of  time 

Artifact 

Communications  Manager  of  the  context-aware  system 

Response 

Communications  Manager  is  changed  to  implement 
message  passing  using  the  new  communication 
mechanism 

Response 

Measure 

Aside  from  communication-mechanism-specific  code, 
only  the  Communications  Manager  is  changed  to 
accommodate  the  new  communications  mechanism. 
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Scenario  5:  Add  a  New  Context  Event  /  Action 


Scenario 

Add  a  New  Cor 

itext  Event/Action 

Attribute 

Extensibility 

Attribute 

Concern 

Separation  of  C 

Concerns 

Scenario 

Stimulus 

Developer 

Refinement 

Stimulus 

Source 

Developer  identifies  a  new  event  that  can  be  detected 
by  examination  of  context  data 

Environment 

Developer  is  sufficiently  comfortable  with  application  to 
make  changes  in  a  reasonable  amount  of  time 

Artifact 

Context  Engine  of  the  context-aware  system 

Response 

Context  Engine  is  changed  to  detect  the  conditions  for 
the  event  and  generate  a  new  action  when  it  is 
detected 

Response 

Measure 

Only  the  Context  Engine  is  changed  to  allow  for 
detection  of  events  and  generation  of  actions 
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Architectural  Decision  1:  Communications 
Interface 


Challenge:  Integration  of  very 
different  communication 
mechanisms 

•  Different  protocols  support  different 
use  cases 

•  Target  hardware  is  unknown 

•  Need  to  adapt  to  target  network 
capability 

Solution 

•  Common  service  interface  provides 
generic  communication  methods 
and  callbacks  that  individual 
protocols  can  adapt  as  necessary 

•  Allows  any  sequence  of 
communication  events  to  account 
for  differences  in  protocols 


connect() 

disconnect!) 

getStatef) 

initialize!) 

sendDataf) 

sendDataToAIIQ 

start)) 

stop() 
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Architectural  Decision  2:  Sensor  Interface 


Challenges 

•  Integration  of  any  current  or  future 
available  sensor 

•  Control  of  sample  rate  and  change 
threshold 

Solution 

•  Common  sensor  interface  provides 
generic  communication  methods 
that  individual  sensor 
implementations  can  adapt  to  as 
appropriate 


Sensor  Manager 


onServiceConnected() 

onServiceDisconnected() 

onServiceUnbound() 

onValueChangedQ 


GPS 

Battery 

Accelerometer 

Light 

Sensor  Service 
Interface 


Legend 


Class  Implements  References 
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Problem 


Peer  review  of  the  architecture  raised  the  issue  that  a  single  thread  would  cause 
high-frequency  sensors  to  overwhelm  the  application 

Simple  experimentation  demonstrated  that  this  was  indeed  a  problem 

Solution 

•  Sensors  implemented  as  Android  Services  (processes  separate  from  the  application) 

•  Communication  via  IPC  to  insulate  application  from  high  poll  rate  impact 

Tradeoff 


Higher  complexity  in  sensor  implementation  although  interface  hides  as  much  as 
possible 


GPS  Service 


Gyroscope  Service 


Battery  Service 


Accelerometer  Service 


Sensor  Manager 


onValueChanged()  [rate  =  20ms] 


onValueChanged()  [rate  =  ^Oms] 


onValueChanged()  [rate  =  100ms] 


onValueChanged()  [rate  =  20  ms] 

I - ^ 
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Architectural  Decision  3:  Context  Model  “At  the 

Center”  View 


Challenges 


WATER  SUPPLY=LOW 


•  Easy  creation  of  rules  based  on 
contextual  data  captured  via 
sensors  or  user  input 


BATTERY_LEVEL=85 
WATER  SUPPLY=LOW 


BATTERY  LEVEL=85 


Application 

Manager 


•  Standardized  rule  processing 

Solutions 

•  Generic  and  extensible  context 
model  that  can  handle  a  wide  range 
of  situations,  environments,  data 

•  Standardized  rule  set  read  by 
application  from  XML  file 


Context 

Engine 


T  radeoff 


If  (BA  TTERY_LEVEL=85)  then 
createAlert(“BA  TTERY  LOW”) 


WATER  SUPPLY=LOW 


jE 


Context  Data 
Manager 

WATER_S 

BATTERY 

BATTERY  LEVEL=85 


Sensor 

Manager 


Context 

Data 


Simple  example 
of  rules  that 
would  codified  in 
XML 


•  Both  sensors  and  views  have  to 
know  the  context  model  element 
that  they  are  affecting  —  strong 
coupling 


If  (WA  TER_SUPPL  Y=LOW)  then 
peer  = 

findPeer(MAX(WA  TER_SUPPL  Y) 
and  (MIN(distance)) 
createMessage(peer  +  “has  water. 
Location  =  “  +  peer. LOCATION) 


Legend 


Logical 

Component 


o  m 

Data  Source  File 


Data  Flow 
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Architectural  Decision  4:  Standardized 
Messaging 


Challenge 


Subscribe  to 
task  creation 
and  task 
updates 


Subscribe  to 
all  data 
changes  in 
user  context 
and  all 
messages 
sent  to  user 
or  all 


Subscribe  to 
all  alerts 


Subscribe  to 
data  changes 
in  location  of 
any  group 
member 


•  Easy  creation  of  views  that  can 
capture  and/or  display  context 
data 


Solution 


•  Publish/subscribe  interface 

-  Standardized  set  of  actions  that  can 
be  created  by  the  context  engine  as 
the  result  of  fired  rules 


sendMessageAll 


-  Application  manager  publishes 
actions  created  by  context  engine  as 
standardized  events 

-  Views  subscribe  to  events 


r 

Legend 


Logical 

Component 

V 


File  Asynchronous 
Callback 


Data 

Read/ 

Write 
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First  Responder  Application  Architecture 


r 

Legend 

\ 

f . 1 

Layer 

■  □  a  -  -  " 

Logical  0*0  Synchronous  Asynchronous  ^ 

~  a  .  Data  Source  File  Ann*  ^  .  Read/ 

Component  Call-Return  Callback  ^ . 
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Results  1 


The  extensible  architecture  enables  productive  collaboration 

•  Sensor  and  communication  service  interface  enable  3rd  parties  to  contribute 
new/novel  sensor  and  protocol  implementations 

•  Standardized  rule  set  approach  allows  enables  adaptation  to  different  context 
data  models 

•  Standardized  messaging  enables  easy  integration  of  new  context  data  views 
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Results  2 


Collaborators  at  GMU  were  able  to  modify  their  unique  communication 
protocol  to  interface  with  application  architecture  in  just  a  few  weeks 


Collaborators  are  working  on  developing  a  group  context  data  model, 
unconstrained  by  implementation  details  and  without  affecting  our 
progress  in  the  meantime 


Collaborators  within  SEI  planning  to  integrate  related  projects  for  QoS 
management,  code  offloading,  and  end-user  programming  with  no 
foreseen  complications 
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Conclusions 


Extensibility  as  an  architecture  driver  enables  productive  collaborative 
research  and  development 


Scenario-driven  architecture  design  along  with  peer  architecture 
evaluation  is  useful  even  for  small  projects 

•  Concrete  definition  of  quality  attribute  requirements 

•  Early  identification  of  risks  and  tradeoffs 
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